home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980424-19980901 / 000117_news@newsmaster….columbia.edu _Fri May 22 13:22:11 1998.msg < prev    next >
Internet Message Format  |  1998-08-31  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA22331
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 22 May 1998 13:22:08 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA03381
  7.     for kermit.misc@watsun; Fri, 22 May 1998 13:22:08 -0400 (EDT)
  8. Path: news.columbia.edu!panix!nntprelay.mathworks.com!cam-news-hub1.bbnplanet.com!wtn-news-feed2.bbnplanet.com!news.bbnplanet.com!netnews.jhuapl.edu!usenet
  9. From: Skip Collins <collibf1@jhuapl.edu>
  10. Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
  11. Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
  12. Date: 22 May 1998 13:11:56 -0400
  13. Organization: Johns Hopkins University Applied Physics Lab, Laurel, MD, USA
  14. Lines: 61
  15. Sender: collibf1@COLLIBF1
  16. Message-ID: <wk67iy1b8j.fsf@jhuapl.edu>
  17. References: <35646665.EBB3868B@theriver.com> <6k1qoj$d92$1@apakabar.cc.columbia.edu> <wkvhqye9g4.fsf@jhuapl.edu> <6k42pd$a3m$1@apakabar.cc.columbia.edu>
  18. NNTP-Posting-Host: collibf1-2.jhuapl.edu
  19. X-Newsreader: Gnus v5.5/Emacs 20.2
  20. Xref: news.columbia.edu comp.protocols.kermit.misc:8770 comp.sys.hp48:81325
  21.  
  22. fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  23. > But we usually find that what works for us fails to work for others, or vice
  24. > versa.  No doubt because there are many and varied HP-48 models, ROM
  25. > versions, etc etc.
  26.  
  27. I should have noted that I am using an HP48GX with ROM R, the latest.
  28.  
  29. >  1. The top serial speed is 9600, right?
  30.  
  31. As far as the built-in kermit is concerned this it true. But there are
  32. user programs that claim to support 19.2k. I have not tried them.
  33.  
  34. >  2. Should the flow control setting be NONE or XON/XOFF?  We have
  35. >     conflicting reports (see above).  Obviously the HP-48 *should* be
  36. >     exercising some form of flow control, but some reports indicate that
  37. >     it does not (even if it is set to do so).
  38.  
  39. Why is flow control necessary or even desirable given the maximum
  40. packet size is 94 and the receive buffer is 255?
  41.  
  42. >  3. Is the link transparent to incoming control characters?  Can the
  43. >     client Kermit program use control-character unprefixing when sending
  44. >     to the HP-48?  If not, the client program must be told to
  45. >     SET CONTROL PREFIX ALL prior to sending files to the HP-48.
  46.  
  47. Shouldn't control char unprefixing be a negotiated feature? If it is
  48. not, I can see where this might be the cause of many people's
  49. problems. Surely it is not the default? I think the physical link is
  50. transparent to control characters. But perhaps the hp48 kermit
  51. software assumes prefixing.
  52.  
  53. >  4. Does the link allow 8-bit data?  If not, the client must be given
  54. >     the appropriate SET PARITY command.
  55.  
  56. Yes, the link allows 8-bit data.
  57.  
  58. > The HP-48 does not support long packets; thus the maximum packet length
  59. > is 94, but this should be negotiated automatically.
  60.  
  61. It is negotiated. As far as I can tell, the only "advanced" feature
  62. supported by the hp48 is a choice of block checking options 1, 2, or 3.
  63.  
  64. > The HP communication port is half duplex, meaning that data can go in both
  65. > directions, but only in one direction at a time.  Therefore sliding windows
  66. > can not be used (this too should be negotiated automatically).
  67.  
  68. The serial port is full duplex. The infrared port is only half-duplex
  69. because of optical feedback. The hp48 kermit certainly has not
  70. implemented sliding windows. There would be very little advantage to
  71. doing so for most users who only use a short cable to connect to a PC.
  72.  
  73. > Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
  74. > "parses" incoming text-mode material on the fly, and appends the material
  75. > from each incoming packet to a "string", resulting in a steadily
  76. > deteriorating transfer rate, at least up to some point at which the HP-48
  77. > dumps the string to storage and starts over with a new string.  There's not
  78. > much that the Kermit client can do about that.
  79.  
  80. This is the biggest problem with hp48 kermit.
  81.  
  82. Skip Collins